home *** CD-ROM | disk | FTP | other *** search
/ Hackers Handbook - Millenium Edition / Hackers Handbook.iso / library / hack / ccxsec.txt < prev    next >
Encoding:
Text File  |  1997-09-25  |  12.4 KB  |  280 lines
  1. X-Windows Security
  2.  
  3. 1. Motivation / introduction
  4. 2. How open X displays are found
  5. 3. The local-host problem
  6. 4. Snooping techniques - dumping windows
  7. 5. Snooping techniques - reading keyboard
  8. 6. Xterm - secure keyboard option
  9. 7. Trojan X programs [xlock and xdm]
  10. 8. X Security tools - xauth MIT-MAGIC-COOKIE
  11. 9. Concluding remarks
  12.  
  13. ---------------------------------------------------------------------------
  14.  
  15. 1. Motivation / introduction
  16.  
  17. X windows pose a security risk. Through a network, anyone can connect to an
  18. open X display, read the keyboard, dump the screen and windows and start
  19. applications on the unprotected display. Even if this is a known fact
  20. throughout the computer security world, few attempts on informing the user
  21. community of the security risks involved have been made. This article deals
  22. with some of the aspects of X windows security. It is in no sense a
  23. complete guide to the subject, but rather an introduction to a not-so-known
  24. field of computer security. Knowledge of the basics of the X windows system
  25. is necessary, I haven't bothered including an introductory section to
  26. explain the fundamentals. I wrote some code during the research for this
  27. article, but none of it is included herein. If the lingual flow of English
  28. seem mayhap strange and erroneous from byte to byte, this is due to the
  29. fact that I'm Scandinavian. Bare with it. :)
  30.  
  31. 2. How open X displays are found
  32.  
  33. An open X display is in formal terms an X server that has its access
  34. control disabled. Disabling access control is normally done with the xhost
  35. command.
  36.  
  37. $ xhost +
  38.  
  39. allows connections from any host. A single host can be allowed connection
  40. with the command
  41.  
  42. $ xhost + ZZZ.ZZZ.ZZZ.ZZZ
  43.  
  44. where Z is the IP address or host-name. Access control can be enabled by
  45. issuing an
  46.  
  47. $ xhost -
  48.  
  49. command. In this case no host but the local-host can connect to the
  50. display. Period. It is as simple as that - if the display runs in 'xhost -'
  51. state, you are safe from programs that scans and attaches to unprotected X
  52. displays. You can check the access control of your display by simply typing
  53. xhost from a shell. Sadly enough, most sites run their X displays with
  54. access control disabled as default. They are therefore easy prey for the
  55. various scanner programs circulating on the net.
  56.  
  57. Anyone with a bit of knowledge about Xlib and sockets programming can write
  58. an X scanner in a couple of hours. The task is normally accomplished by
  59. probing the port that is reserved for X windows, number 6000. If anything
  60. is alive at that port, the scanner calls XOpenDisplay("IP-ADDRESS:0.0")
  61. that will return a pointer to the display structure, if and only if the
  62. target display has its access control disabled. If access control is
  63. enabled, XOpenDisplay returns 0 and reports that the display could not be
  64. opened.
  65.  
  66. E.g:
  67.  
  68. Xlib: connection to "display:0.0" refused by server
  69. Xlib: Client is not authorized to connect to Server
  70.  
  71. The probing of port 6000 is necessary because of the fact that calling
  72. XOpenDisplay() on a host that runs no X server will simply hang the calling
  73. process. So much for unix programming conventions. :)
  74.  
  75. I wrote a program called xscan that could scan an entire subnet or scan the
  76. entries in /etc/hosts for open X displays. My remark about most sites
  77. running X displays with access control disabled, originates from running
  78. xscan towards several sites on the internet.
  79.  
  80. 3. The localhost problem
  81.  
  82. Running your display with access control enabled by using 'xhost -' will
  83. guard you from XOpenDisplay attempts through port number 6000. But there is
  84. one way an eavesdropper can bypass this protection. If he can log into your
  85. host, he can connect to the display of the localhost. The trick is fairly
  86. simple. By issuing these few lines, dumping the screen of the host 'target'
  87. is accomplished:
  88.  
  89. $ rlogin target
  90. $ xwd -root -display localhost:0.0 > ~/snarfed.xwd
  91. $ exit
  92. $ xwud -in ~/snarfed.xwd
  93.  
  94. And voila, we have a screendump of the root window of the X server target.
  95.  
  96. Of course, an intruder must have an account on your system and be able to
  97. log into the host where the specific X server runs. On sites with a lot of
  98. X terminals, this means that no X display is safe from those with access.
  99. If you can run a process on a host, you can connect to (any of) its X
  100. displays.
  101.  
  102. Every Xlib routine has the Display structure as it's first argument. By
  103. successfully opening a display, you can manipulate it with every Xlib call
  104. available. For an intruder, the most 'important' ways of manipulating is
  105. grabbing windows and keystrokes.
  106.  
  107. 4. Snooping techniques - dumping windows
  108.  
  109. The most natural way of snarfing a window from an X server is by using the
  110. X11R5 utility xwd or X Window System dumping utility. To get a grip of the
  111. program, here's a small excerpt from the man page
  112.  
  113. DESCRIPTION
  114.  
  115.      Xwd is an X Window System window dumping utility. Xwd allows Xusers to
  116.      store window images in a specially formatted dump file. This file can
  117.      then be read by various other X utilities for redisplay, printing,
  118.      editing, formatting, archiving, image processing, etc. The target
  119.      window is selected by clicking the pointer in the desired window. The
  120.      keyboard bell is rung once at the beginning of the dump and twice when
  121.      the dump is completed.
  122.  
  123. Shortly, xwd is a tool for dumping X windows into a format readable by
  124. another program, xwud. To keep the trend, here's an excerpt from the man
  125. page of xwud:
  126.  
  127. DESCRIPTION
  128.  
  129.      Xwud is an X Window System image undumping utility. Xwud allows X
  130.      users to display in a window an image saved in a specially formatted
  131.      dump file, such as produced by xwd(1).
  132.  
  133. I will not go in detail of how to use these programs, as they are both
  134. self-explanatory and easy to use. Both the entire root window, a specified
  135. window (by name) can be dumped, or a specified screen. As a 'security
  136. measure' xwd will beep the terminal it is dumping from, once when xwd is
  137. started, and once when it is finished (regardless of the xset b off
  138. command). But with the source code available, it is a matter of small
  139. modification to compile a version of xwd that doesn't beep or otherwise
  140. identifies itself - on the process list e.g. If we wanted to dump the root
  141. window or any other window from a host, we could simply pick a window from
  142. the process list, which often gives away the name of the window through the
  143. -name flag. As before mentioned, to dump the entire screen from a host:
  144.  
  145. $ xwd -root localhost:0.0 > file
  146.  
  147. the output can be directed to a file, and read with
  148.  
  149. $ xwud -in file
  150.  
  151. or just piped straight to the xwud command.
  152.  
  153. Xterm windows are a different thing. You can not specify the name of an
  154. xterm and then dump it. They are somehow blocked towards the X_Getimage
  155. primitive used by xwd, so the following
  156.  
  157. $ xwd -name xterm
  158.  
  159. will result in an error. However, the entire root window (with Xterms and
  160. all) can still be dumped and watched by xwud. Some protection.
  161.  
  162. 5. Snooping techniques - reading keyboard
  163.  
  164. If you can connect to a display, you can also log and store every keystroke
  165. that passes through the X server. A program circulating the net, called
  166. xkey, does this trick. A kind of higher-level version of the infamous
  167. ttysnoop.c. I wrote my own, who could read the keystrokes of a specific
  168. window ID (not just every keystroke, as my version of xkey). The window
  169. ID's of a specific root-window, can be acquired with a call to
  170. XQueryTree(), that will return the XWindowAttributes of every window
  171. present. The window manager must be able to control every window-ID and
  172. what keys are pressed down at what time. By use of the window-manager
  173. functions of Xlib, KeyPress events can be captured, and KeySyms can be
  174. turned into characters by continuous calls to XLookupString.
  175.  
  176. You can even send KeySym's to a Window. An intruder may therefore not only
  177. snoop on your activity, he can also send keyboard events to processes, like
  178. they were typed on the keyboard. Reading/writing keyboard events to an
  179. xterm window opens new horizons in process manipulation from remote.
  180. Luckily, xterm has good protection techniques for prohibiting access to the
  181. keyboard events.
  182.  
  183. 6. Xterm - Secure keyboard option
  184.  
  185. A lot of passwords is typed in an xterm window. It is therefore crucial
  186. that the user has full control over which processes can read and write to
  187. an xterm. The permission for the X server to send events to an Xterm
  188. window, is set at compile time. The default is false, meaning that all
  189. SendEvent requests from the X server to an xterm window is discarded. You
  190. can overwrite the compile-time setting with a standard resource definition
  191. in the .Xdefaults file:
  192.  
  193. xterm*allowSendEvents   True
  194.  
  195. or by selecting Allow Sendevents on the Xterm Main Options menu. (Accessed
  196. by pressing CTRL and the left mouse button But this is _not_ recommended.
  197. Neither by me, nor the man page. ;) Read access is a different thing.
  198.  
  199. Xterms mechanism for hindering other X clients to read the keyboard during
  200. entering of sensitive data, passwords etc. is by using the XGrabKeyboard()
  201. call. Only one process can grab the keyboard at any one time. To activate
  202. the Secure Keyboard option, choose the Main Options menu in your Xterm
  203. window (CTRL+Left mouse button) and select Secure Keyboard. If the colors
  204. of your xterm window inverts, the keyboard is now Grabbed, and no other X
  205. client can read the KeySyms.
  206.  
  207. The versions of Xterm X11R5 without patch26 also contain a rather nasty and
  208. very well known security hole that enables any user to become root through
  209. clever use of symbolic links to the password file. The Xterm process need
  210. to be setuid for this hole to be exploitable. Refer to the Cert Advisory:
  211. CA-93:17.xterm.logging.vulnerability.
  212.  
  213. 7. Trojan X clients - xlock and X based logins
  214.  
  215. Can you think of a more suitable program for installing a password-grabbing
  216. trojan horse than xlock? I myself cannot. With a few lines added to the
  217. getPassword routine in xlock.c, the password of every user using the trojan
  218. version of xlock can be stashed away in a file for later use by an
  219. intruder. The changes are so minimal, only a couple of bytes will tell the
  220. real version from the trojan version.
  221.  
  222. If a user has a writable homedir and a ./ in her PATH environment variable,
  223. she is vulnerable to this kind of attack. Getting the password is achieved
  224. by placing a trojan version of Xlock in the users homedir and waiting for
  225. an invocation. The functionality of the original Xlock is contained in the
  226. trojan version. The trojan version can even tidy up and destroy itself
  227. after one succesfull attempt, and the user will not know that his password
  228. has been captured.
  229.  
  230. Xlock, like every password-prompting program, should be regarded with
  231. suspicion if it shows up in places it should not be, like in your own
  232. homedir.
  233.  
  234. Spoofed X based logins however are a bit more tricky for the intruder to
  235. accomplish. He must simulate the login screen of the login program ran by
  236. XDM. The only way to ensure that you get the proper XDM login program (if
  237. you want to be really paranoid) is to restart the X-terminal, whatever key
  238. combination that will be for the terminal in question.
  239.  
  240. 8. X Security tools - xauth MIT-MAGIC-COOKIE
  241.  
  242. To avoid unathorized connections to your X display, the command xauth for
  243. encrypted X connections is widely used. When you login, xdm creates a file
  244. .Xauthority in your homedir. This file is binary, and readable only through
  245. the xauth command. If you issue the command
  246.  
  247. $ xauth list
  248.  
  249. you will get an output of:
  250.  
  251. your.display.ip:0 MIT-MAGIC-COOKIE-1 73773549724b76682f726d42544a684a
  252.  
  253.   display name     authorization type               key
  254.  
  255. The .Xauthority file sometimes contains information from older sessions,
  256. but this is not important, as a new key is created at every login session.
  257. To access a display with xauth active - you must have the current access
  258. key.
  259.  
  260. If you want to open your display for connections from a particular user,
  261. you must inform him of your key. He must then issue the command
  262.  
  263. $ xauth add your.display.ip:0  MIT-MAGIC-COOKIE-1 73773549724b7668etc.
  264.  
  265. Now, only that user (including yourself) can connect to your display.
  266. Xauthority is simple and powerful, and eliminates many of the security
  267. problems with X.
  268.  
  269. 9. Concluding remarks
  270.  
  271. Thanks must go to Anthony Tyssen for sending me his accumulated info on X
  272. security issues from varius usenet discussions. I hope someone has found
  273. useful information in this text. It is released to the net.community with
  274. the idea that it will help the user to understand the security problems
  275. concerned with using X windows. Questions or remarks can be sent to the
  276. following address:
  277.  
  278. ---------------------------------------------------------------------------
  279. runeb / cF --- runeb@stud.cs.uit.no --- http://www.cs.uit.no/~runeb
  280.